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ABSTRACT 


The Real-Time Specification for Java (RTSJ) allows a pro- 
gram to create real-time threads with hard real-time con- 
straints. Real-time threads use immortal memory and 
region-based memory management to avoid unbounded 
pauses caused by interference from the garbage collector. 
The RTSJ uses runtime checks to ensure that deleting a re- 
gion does not create dangling references and that real-time 
threads do not access references to objects allocated in the 
garbage-collected heap. This paper presents a static type 
system that guarantees that these runtime checks will never 
fail for well-typed programs. Our type system therefore 1) 
provides an important safety guarantee for real-time pro- 
grams and 2) makes it possible to eliminate the runtime 
checks and their associated overhead. 

Our system also makes several contributions over previ- 
ous work on region types. For object-oriented programs, it 
combines region types and ownership types in a unified type 
system framework. For multithreaded programs, it allows 
long-lived threads to share objects without using the heap 
and without having memory leaks. For real-time programs, 
it ensures that real-time threads do not interfere with the 
garbage collector. 

We have implemented several programs in our system. 
Our experience indicates that our type system is sufficiently 
expressive and requires little programming overhead. We 
also ran these programs on our RTSJ platform. Our experi- 
ments show that eliminating the RTSJ runtime checks using 
a static type system can significantly decrease the execution 
time of a real-time program. 


1. INTRODUCTION 


The Real-Time Specification for Java (RTSJ) [6] provides 
a framework for building real-time systems. The RTSJ al- 
lows a program to create real-time threads with hard real- 
time constraints. These real-time threads cannot use the 
garbage-collected heap because they cannot afford to be in- 
terrupted for unbounded amounts of time by the garbage 
collector. Instead, the RTSJ allows these threads to use ob- 
jects allocated in immortal memory (which is never garbage 
collected) or in regions [36]. Region-based memory manage- 
ment systems structure memory by grouping objects in re- 
gions under program control. Memory is reclaimed by delet- 
ing regions, freeing all objects stored therein. The RTSJ 
uses runtime checks to ensure that deleting a region does 
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not create dangling references and that real-time threads do 
not access heap references. 

This paper presents a static type system for writing real- 
time programs in Java. Our system guarantees that the 
above-mentioned RTSJ runtime checks will never fail for 
well-typed programs. Our system can serve as a front-end 
for the RTSJ platform. It offers two advantages to real-time 
programmers. First, it provides a safety guarantee that the 
program will never fail because of a failed access check. Sec- 
ond, if an RTSJ implementation allows disabling the RTSJ 
runtime checks, then programs written in our system can 
run more efficiently without risking memory errors. 

Our approach is applicable even outside the RTSJ con- 
text. In fact, it could be adapted to provide safe region- 
based memory management for virtually any type-safe real- 
time language. Given the advantages of using regions and 
immortal memory in real-time systems, we believe our tech- 
nology will be relevant in whatever type-safe real-time lan- 
guage eventually emerges as the industry standard. 


Our system also makes several important technical con- 
tributions over previous work on type systems for region- 
based memory management. For object-oriented programs, 
it combines region types [36, 17, 26, 30] and ownership 
types [14, 13, 7, 8] in a unified type system framework. 
Region types statically ensure that programs never follow 
dangling references. Ownership types provide a statically 
enforceable way of specifying object encapsulation. Owner- 
ship types enable modular reasoning about program correct- 
ness. Consider, for example, a Stack object s that is imple- 
mented using a Vector subobject v. To reason locally about 
the correctness of the Stack implementation, a programmer 
must know that v is not directly accessed by objects outside 
s. With ownership types, a programmer can declare that s 
owns v. The type system then statically ensures that v is 
encapsulated within s. 

In an object-oriented language that only has region types 
(eg., [30]), the types of s and v would declare that they are 
allocated in some region r. In an object-oriented language 
that only has ownership types, the type of v would declare 
that it is owned by s. Our type system provides a simple 
unified mechanism to declare both properties. The type of 
s can declare that it is allocated in r and the type of v can 
declare that it is owned by s. Our system then statically 
ensures that both objects are allocated in r, that there are 
no pointers to v and s after r is deleted, and that v is en- 
capsulated within s. We thus combine the benefits of region 
types and ownership types. 


Our system extends region types to multithreaded pro- 
grams by allowing explicit memory management for objects 
shared between threads. Our system allows threads to com- 
municate through objects in shared regions in addition to 
the heap. A shared region is deleted when all threads exit 
the region. However, programs in a system with just shared 
regions (eg., [25]) will have memory leaks if two long-lived 
threads communicate by creating objects in a shared region. 
This is because the objects will not be deleted until both 
threads exit the shared region. To solve this problem, we 
introduce the notion of subregions within a shared region. A 
subregion can be deleted more frequently, for example, after 
each loop iteration in the long-lived threads. 

Our system also introduces typed portal fields in subre- 
gions to serve as a starting point for inter-thread communi- 
cation. Portals also allow typed communication, so threads 
do not have to downcast from Object to more specific types. 
Typed communication prevents more errors statically. Our 
system introduces user-defined region kinds to support sub- 
regions and portal fields. 


Our system extends region types to real-time programs by 
using effects clauses [29] to statically check that real-time 
threads do not interfere with the garbage collector. Our 
system augments region kind declarations with region policy 
declarations. We support two policies for creating regions 
as in RTSJ. A region can be an LT (Linear Time) region, or 
a VT (Variable Time) region. Memory for an LT region is 
preallocated at region creation time, so allocating an object 
in an LT region only takes time proportional to the size of 
the object (because all the bytes have to be zeroed). Mem- 
ory for a VT region is allocated on demand, so allocating 
an object in a VT region takes variable time. Our system 
checks that real-time threads do not use heap references, 
create new regions, or allocate objects in VT regions. 

Most previous region type systems allow programs to cre- 
ate, but not follow, dangling references. Such references can 
cause a safety problem when used with copying collectors. 
We therefore prevent a program from creating dangling ref- 
erences in the first place. 


Contributions 
To summarize, this paper makes the following contributions: 


e Region types for object-oriented programs: Our 
system combines region types and ownership types in a 
unified type system framework that statically enforces 
object encapsulation as well as enables safe region- 
based memory management. 


e Region types for multithreaded programs: Our 
system introduces subregions within a shared region, 
so long-lived threads can share objects without using 
the heap and without having memory leaks. Our sys- 
tem also introduces typed portal fields to serve as a 
starting point for typed inter-thread communication. 
Our system introduces user-defined region kinds to 
support subregions and portals. 


e Region types for real-time programs: Our system 
allows programs to create LT (Linear Time) and VT 
(Variable Time) regions as in RTSJ. It checks that 
real-time threads do not use heap references, create 
new regions, or allocate objects in VT regions, so that 
they do not wait for unbounded amounts of time. 


e Type inference: Our system uses a combination of 
intra-procedural type inference and well-chosen defaults 
to significantly reduce programming overhead. Our 
approach permits separate compilation. 


e Experience: We implemented several programs in 
our system. Our experience indicates that our type 
system is sufficiently expressive and requires little pro- 
gramming overhead. We also ran these programs on 
our RTSJ platform [4, 5, 22]. Our experiments show 
that eliminating the RTSJ dynamic checks using a 
static type system can significantly speed-up a real- 
time program. 


Outline 


The paper is organized as follows. Section 2 describes our 
type system. Section 3 describes our experimental results. 
Section 4 presents related work. Section 5 concludes. 


2. TYPE SYSTEM 


This section presents our type system for safe region-based 
memory management. Sections 2.1, 2.2, and 2.3 provide an 
informal sketch of the type system. Section 2.4 presents 
some of the important rules for typechecking. The full set 
of rules are in the appendix. Section 2.5 describes type in- 
ference techniques that reduce programming overhead. Sec- 
tion 2.6 describes how programs in written our system are 
translated to run on our RTSJ platform. 


2.1 Regions for Object Oriented Programs 


This section presents our type system for region-based 
memory management in object-oriented programs. It com- 
bines region types [36, 17, 26, 30] and ownership types [14, 
13, 7, 8]. Region types statically ensure that programs using 
region-based memory management are memory-safe, that 
is, they never follow dangling references. Ownership types 
provide a statically enforceable way of specifying object en- 
capsulation. The idea is that an object can own subobjects 
that it depends on, thus preventing them from being ac- 
cessible outside. (An object a depends on subobject 6 [28] 
if a calls methods of b and furthermore these calls expose 
mutable behavior of b in a way that affects the invariants 
of a.) Object encapsulation enables local reasoning about 
program correctness. Ownership types have also been used 
for statically preventing data races [9] and deadlocks [7] in 
Java programs, for supporting safe lazy upgrades in object- 
oriented databases [8], and for program understanding [3]. 
Our type system is based on the type system in [8]. 


Ownership Relation Objects are allocated in regions. 
Every object in our system has an owner. An object can be 
owned by another object, or by a region. We write 01 =o 02 
if oi directly or transitively owns o2 or if 01 is the same as 
og. The relation >, is thus the reflexive transitive closure 
of the owns relation. Our type system statically guarantees 
the properties in Figure 1. O1 states that our ownership 
relation has no cycles. O2 states that if an object is owned 
by a region, then that object and all its subobjects are allo- 
cated in that region. O3 states the encapsulation property 
of our system, that if y is inside the encapsulation boundary 
of z and z is outside, then « cannot access y.1 An object 


‘Our system handles inner class objects specially to support 
constructs like iterators. Details can be found in [8]. 


Ol. The ownership relation forms a forest of trees. 


O2. If region r =, object x, then z is allocated in r. 


O3. If object z =, y but z 7, x, then x cannot access y. 


Figure 1: Ownership Properties 


R1. For any region r, heap = r and immortal = r. 
R2.¢>oy—=> Urry. 


R3. If region r; >, object 01, region r2 =, object o2, and 
T1 = 2, then o2 cannot contain a pointer to 01. 


Figure 2: Outlives Properties 


accesses an object y if x has a pointer to y, or methods of 
x obtain a pointer to y. Figure 6 shows an example owner- 
ship relation. We draw a solid line from x to y if x owns y. 
Region r2 owns sl, sl owns sl.head and s1.head.next, etc. 


Outlives Relation Our system allows a program to create 
regions. Our system also provides two special regions: the 
garbage collected region heap, and the “immortal” region 
immortal. The lifetime of a region is the time interval from 
when the region is created until it is deleted. If the lifetime 
of region r; includes the lifetime of region r2, we say that 
r, outlives ro, and write r, > r2. We extend the outlives 
relation to include objects. The extension is natural: if 
object 01 owns object o2, then 0; outlives 02, because 02 
is accessible only through 0;. Also, if region r owns object 
obj, then obj is allocated in r, and therefore r outlives obj. 
In all cases, x =. y implies « = y. Our outlives relation 
has the properties shown in Figure 2. R1 states that heap 
and immortal outlive all regions. R2 states that the outlives 
relation includes the ownership relation. R3 implies that 
there are no dangling references in our system. Figure 6 
shows an example outlives relation. We draw a dashed line 
from region x to region y if x outlives y. In the example, 
region rl outlives region r2, and heap and immortal outlive 
all regions. Using the above definitions, we can prove the 
following easy lemmas: 


LEMMA 1. If object 01 = object 02, then 01 ~o 02. 


LEMMA 2. If region r = object o, then there exists a unique 
region r’ such that r> 1’ andr’ >, 0. 


Grammar To simplify the presentation of key ideas behind 
our approach, we describe our type system formally in the 
context of a core subset of Java known as Classic Java [21]. 
Our approach, however, extends to the whole of Java and 
other similar languages. Figure 3 presents the grammar for 
our core language. A program consists of a series of class 
declarations followed by an initial expression. A predefined 
class Object is the root of the class hierarchy. 


Owner Polymorphism Every class definition is parame- 
terized with one or more owners. (This is similar to para- 
metric polymorphism [32, 10, 1] except that our parameters 
are values, not types.) An owner can be an object or a re- 
gion. Parameterization allows programmers to implement a 
generic class whose objects can have different owners. The 


P :s= def*e 
def := class cn(formal+) extends c 
where constr* { field* meth* } 
formal := &k fn 
ec =  en(owner+) | Object(owner) 
owner := fn |r| this | initialRegion 
field w= + fd 
meth s:= t mn(formal*)((t p)*) where constr™ { e } 
constr = owner owns owner | owner outlives owner | 
t :=  c| int | RHandle(r) 
ko ::= Owner | ObjOwner | rkind 
rkind ::= Region | GCRegion | NoGCRegion | LocalRegion 
eo: vu |h_heap | h_immortal | let v = e in { e } | 
v.fd | v.fd =v | v.mn(owner*)(v*) | 
new c | (RHandle(r) h) { e } 
h = 29. 
cn € class names 
fda € field names 
mn € method names 
fn € formal identifiers 
v,p € variable names 
r €__ region identifiers (including heap, immortal) 


Figure 3: Grammar for Object Oriented Programs 
Owner ®M 


ObjOwner Region 


NoGCRegion GCRegion 


LocalRegion _ ~< SharedRegion @ 


N 


@ NHPRegion *S user defined region kinds 


N 
N 
\ 


user defined region kinds 


Figure 4: Owner Kind Hierarchy: Section 2.1 uses 
only Area 1. Sections 2.2 & 2.3 use Areas 2 & 3. 


first formal owner is special: it owns the this object; the 
other owners propagate the ownership information. If neces- 
sary, methods can declare an additional list of formal owner 
parameters. Each time new formals are introduced, pro- 
grammers can specify constraints between them using where 
clauses [18]. The constraints have the form “o,; owns 02” 
(ie., 01 =o 02) and “o; outlives 02” (i.e., 01 = 02). 

Each formal has an owner kind. There is a subkinding 
relation between owner kinds, resulting in the kind hier- 
archy from the upper half of Figure 4. The hierarchy is 
rooted in Owner, that has two subkinds: ObjOwner (owners 
that are objects, we avoid using Object because it is already 
used for the root of the class hierarchy) and Region. Region 
has two subkinds: GCRegion (the kind of the garbage col- 
lected heap) and NoGCRegion (for the normal regions). Fi- 
nally, NoGCRegion has a single subkind, LocalRegion. (At 
this point, there is no distinction between NoGCRegion and 
LocalRegion. We will add new kinds in the next sections.) 


Region Creation The expression “(RHandle(r) h) {e}” 
creates a new region and introduces two identifiers r and h 
that are visible inside the scope of e. r is an owner of kind 
LocalRegion that is bound to the newly created region. h 
is a runtime value of type RHandle(r) that is bound to the 
handler of the region r. The region name r is only a type- 
checking entity; it is erased (together with all the ownership 
and region type annotations) immediately after typecheck- 
ing. However, the region handle h is required at runtime 


when we allocate objects in region r; object allocation is ex- 
plained in the next paragraph. The newly created region is 
outlived by all regions that existed when it was created; it is 
destroyed at the end of the scope of e. This corresponds to a 
“last in first out” region lifetime. As we mentioned before, in 
addition to the user created regions, we have special regions: 
the garbage collected region heap (with handle h_heap) and 
the “immortal” memory immortal (with handle h_immortal). 
Objects allocated in the immortal region are never deallo- 
cated. heap and immortal are never destroyed; hence, they 
outlive all regions. We also allow methods to allocate ob- 
jects in initialRegion. The special region initialRegion denotes 
the most recent region that was created before the method 
was called. We use runtime support to acquire the handle 
of initialRegion. 


Object Allocation New objects are created using the ex- 
pression “new cn(01..n)”. 01 is the owner of the new object. 
If 01 is a region, the new object is allocated there; otherwise, 
it is allocated in the region where the object 01 is allocated. 
For the purpose of typechecking, region handles are unnec- 
essary. However, at runtime we need a handle of the region 
we allocate in. The type rules check that we can obtain such 
a handle (more details in Section 2.4). If 0; is a region r, 
a handle of r must be in the environment. Therefore, if a 
method has to allocate memory in a specific region that is 
passed to it as an owner parameter, then it also needs to 
receive the corresponding region handle as an argument. 

We can instantiate a formal owner parameter with an in- 
scope formal, a region name, or the this object. For every 
type cn(0i..n) with multiple owners, our type system stati- 
cally enforces the constraint that 0; = 01, for all 7 € {1..n}. 
In addition, if an object of type cn(o1..n) has a method mn, 
and if a formal owner parameter of mn is instantiated with 
an object obj, then our system ensures that obj > 01. These 
restriction enable the type system to statically enforce ob- 
ject encapsulation and prevent dangling references. 


Example We illustrate our type system with the example 
in Figure 5. A TStack is a stack of T objects. It is imple- 
mented using a linked list. The TStack class is parameter- 
ized by stackOwner and TOwner. stackOwner owns the new 
TStack object and TOwner owns the T objects contained in 
the TStack. The code specifies that the stack object owns 
the list; therefore the list cannot be accessed from outside 
the stack object. The program creates two regions ri and r2 
such that r1 outlives r2, and declares several stacks: s1 is 
a stack allocated in region r2, whose elements are allocated 
in r2; s2 is a stack allocated in r2, with elements in r1; 
etc. However, the declaration of s6 does not typecheck. It 
is declared as a stack allocated in r1, with elements from r2. 
In each instantiation of TStack, all owners must outlive the 
first owner, but r2 does not outlive r1; if this declaration 
were legal, when r2 is deallocated we would obtain several 
dangling pointers from the TNode objects. Figure 6 presents 
the ownership and the outlives relations from this example, 
(assuming the stacks contain two elements each). We use 
circles for objects, rectangles for regions, solid arrows for 
ownership and dashed arrows for the outlives relation be- 
tween regions. 


Safety Guarantees The following two theorems summa- 
rize our safety guarantees. Theorem 3.1 states the memory 


class TStack<Owner stackOwner, Owner TOwner> { 
TNode<this, TOwner> head = null; 


void push(T<TOwner> value) { 
TNode<this, TOwner> newNode = new TNode<this, TOwner>; 
newNode.init(value, head); head = newNode; 


} 


T<TOwner> pop() { 
if(head == null) return null; 
T<TOwner> value = head.value; head = head.next; 
return value; 
} 
} 


class TNode<Owner nodeQwner, Owner TOwner> { 
T<TOwner> next; 
TNode<nodeOwner, TOwner> next; 


void init(T<TOwner> v, TNode<nodeOwner, TOwner> n) { 
this.value =v; this.next = n; 
- 
} 


(RHandle<ri> hi) { 
(RHandle<r2> h2) { 


TStack<r2, r2> si; 
TStack<r2, ri> s2; 
TStack<ri, immortal> s3; 


TStack<heap, immortal> s4; 
TStack<immortal, heap> s5; 
/* TStack<ri, r2> s6; illegal! */ 
/* TStack<heap, ri> s7; illegal! */ 
+ } 
Figure 5: Stack of T Objects 
oa aa 
heap [<= ---------- | immortal 
12 ye = 
sl (TStack) s2 (TStack) 
O O 
slhead /sI.head.néxt  s2.head A2.head. s3.head.next 


(TNode (TNode) (TNode) jode) 


s3.head.value 
(T) 


(T) (T) (T) 


s2.head.value 
(T) 


sl_.head.value 


(T) 


s|.head.next.value s2.head.next.value s3.head.next.value 


Figure 6: TStack Ownership and Outlives Relations 


safety property. Theorems 3.2 and 4 state the object encap- 
sulation property. Note that objects owned by regions are 
not encapsulated within other objects. 


THEOREM 3. If objects 01 and o2 are allocated in regions 
r1 and ro respectively, and field fd of 01 points to 02, then 


1. ro outlives 1. 


2. Either owner of 02 ~o 01, or owner of 02 is a region. 


PROOF. Suppose class cn(fi.n){.-. T(@1,..-) fd ...} is the 
class of 01. Field fd of type T (1, ...) contains a reference to 
02. £1 must therefore own 02. x1 can therefore be either 1) 
heap, or 2) immortal, or 3) this, or 4) f;, a class formal. In 
the first two cases, ro = 41 > 71, and owner of 0g = x1 isa 
region. In Case 3, r2 = m1 = m1, and owner of 02 = 01 ~o 01. 
In Case 4, we know that f; = f1, since all owners in a legal 
type outlive the first owner. Therefore, owner of 02 = 41 = 
fi = fi = this = 01. If owner of 02 is an object, we know 
from Lemma 1 that owner of 02 >» 01. This also implies 


that ro = 1 = mr. If the owner of o2 is a region, we know 
from Lemma 2 that there exists region r such that owner of 
02 = rand r >> 01. For the last relation to be true, re = r 
ae Aes 


THEOREM 4. If a variable v in a method mn of an object 
01 points to an object 02, then either owner of 02 =o 01, or 
owner of 02 1s a region. 


PrRoorF. Similar to the proof of Theorem 3, except that 
now we have a fifth possibility for the owner of 02: a formal 
method parameter that is a region or initialRegion (that are 
not required to outlive 01). In this case, owner of o2 is a 
region. The other four cases are identical. 


2.2 Regions for Multithreaded Programs 


In this section, we extend our language to allow multi- 
threaded programs. Figure 7 presents the language exten- 
sions. A fork is similar to a method call, except that the 
invoked method is evaluated in a concurrent thread; the 
parent thread does not wait for the completion of the new 
thread, and the result of the method is not used. Our un- 
structured concurrency model (similar to Java’s model) is 
incompatible to the regions from Section 2.1 whose lifetime 
is lexically bound. Those regions can still be used for allocat- 
ing objects that are thread local (hence the name of the asso- 
ciated region kind, LocalRegion), but objects shared by mul- 
tiple threads require shared regions, of kind SharedRegion. 


Shared Regions “(RHandle(rkind r) h) {e}” creates a 
shared region (ignore rkind for the moment); inside expres- 
sion e, the identifiers r and h are bound to the region, re- 
spectively the region handle. Inside e, r and h can be passed 
to children threads. The objects allocated inside a shared 
region are not deallocated as long as some thread can still ac- 
cess them. To ensure this, each thread maintains a stack of 
shared regions it can access, and each shared region main- 
tains a counter of how many such stacks it is an element 
of. When a new shared region is created, it is pushed on 
the stack and its counter is initialized to 1. A child thread 
inherits all the shared regions of its parent thread; the coun- 
ters of these regions are incremented when the child thread 
is forked. When the scope of a region name ends (the names 
of the shared regions are still lexically scoped, even if their 
lifetimes are not), the corresponding region is popped off 
the stack and its counter is decremented. When a thread 
terminates, the counters of all the regions from its stack are 
decremented. If the counter of a region ever becomes zero, 
the region is deleted. The typing rule for fork checks that 
no argument passed to the started thread is allocated in a 
local region; it also checks that no owner passed to the child 
thread is a local region. 


Subregions and Portals Shared regions provide the ba- 
sis of inter-thread communication. However, in many cases, 
they are not enough. E.g., imagine two threads, a producer 
and a consumer, that communicate through a shared region 
in a repetitive way. In each iteration, the producer allocates 
some objects in the shared region, that are subsequently 
used by the consumer. These objects become unreachable 
after each iteration. However, these objects are not deallo- 
cated until the two threads terminate and exit the shared 
region. To solve this memory leak, we allow shared regions 
to have subregions. In each iteration, the producer and the 


P :=  def* srkdef* e 
srkdef ::= regionKind srkn(formal*) extends srkind 
where constr* { field* subsreg* } 
rkind :=  ... asin Figure 3 ... | srkind 
srkind :=  srkn(owner™) | SharedRegion 
subsreg = srkind rsub 
e u= .. asin Figure 3... | 
fork v.mn(owner*)(v*) | 
(RHandle(rkind r) h) { e } | 
(RHandle(r) h = [newlopt h.rsub) { e } | 
h.fd | h.fd =v 
srkn € shared region kind names 
rsub € shared subregion names 


Figure 7: Extensions for Multithreaded Programs 


consumer enter a subregion of the shared region and use it 
to allocate/read the object they want to communicate. At 
the end of the iteration, both threads exit the subregion, its 
reference count goes to zero, and its objects are deallocated. 
To allow the two threads to pass the references of the ob- 
jects they want to communicate, we allow (sub)regions to 
have portal fields. Notice that storing the references in the 
fields of a “hook” object is not possible: objects allocated 
outside the subregion cannot point down inside the region 
and objects allocated in the subregion do not survive be- 
tween iterations, hence being unusable as “hooks”. 


Region Kinds In practice, programs can declare several 
shared region kinds. Each such kind extends another shared 
region kind and can declare several fields and/or subregions 
(see grammar rule for srkdef in Figure 7). The resulting 
shared region kind hierarchy has SharedRegion as its root. 
The new owner kind hierarchy consists of Areas 1 and 2 
from Figure 4. Similar to classes, shared region kinds can 
be generalized with respect to a list of owners that are used 
in the field types; unlike objects, regions are not owned by 
anybody so there is no special meaning attached to the first 
owner. “(RHandle(r2) ha = [newlopt hi.rsub) {e}” evalu- 
ates expression e in an environment where r2 is bound to the 
subregion rsub of the region r; that hy is a handle of, and hy 
is bound to the handle of r. In addition, if the keyword new 
is present, r is a newly created region, distinct from the pre- 
vious rsub subregion. If h is a handle of a region r, “h. fd” 
reads r’s shared field fd, and “h.fd = v” stores a value into 
that field. The rule for region fields is the same as that for 
object fields: a shared field of a region r is required to point 
to an object allocated in r or in a region that outlives r. 


Example ‘Figure 8 contains an example that illustrates 
the use of region fields and subregions. The main thread cre- 
ates a shared region of kind CommunicationRegion and then 
starts two threads, a producer and a consumer, that commu- 
nicate through the shared region. In each iteration, the pro- 
ducer enters the buffer subregion (of kind FrameBuffer), 
allocates a Frame object in it, and stores a reference to the 
frame in subregion’s field £. Next, the producer exits the 
subregion and waits for the consumer. As f is non-null, the 
subregion is not flushed. The consumer enters the subre- 
gion, uses the frame object pointed to by its f field, sets 
that field to null, and exits the subregion. Now, the sub- 
region is flushed (its counter is zero and all its fields are 
null) and a new iteration is able to start. In this paper, we 


regionKind FrameBuffer extends SharedRegion { 
Frame<this> f; 


} 


regionKind CommunicationRegion extends SharedRegion { 
FrameBuffer buffer; 


} 


class Producer<CommunicationRegion r> { 
void run(RHandle<r> h) { 
while(true) { 

(RHandle<FrameBuffer buffer> hbuffer = h.buffer) { 
Frame<buffer> frame = new Frame<buffer>; 
grab_image (frame) ; 
hbuffer.f = frame; 

} 

. // wake up the consumer 
. // wait for the consumer 


33} 


class Consumer<CommunicationRegion r> { 
void run(RHandle<r> h) { 
while(true) { 
. // wait for the producer 
(RHandle<FrameBuffer buffer> hbuffer = h.buffer) { 
Frame<buffer> frame = hbuffer.f; 
hbuffer.f = null; 
process_image (frame) ; 
} 
. // wake up the producer 
33} 


(RHandle<CommunicationRegion r> h) { 
fork (new Producer<r>).run(h) ; 
fork (new Consumer<r>) .run(h) ; 


} 


Figure 8: Producer Consumer Example 


do not discuss synchronization issues; the synchronization 
primitives in the example are similar to those in Java. 


Flushing Subregions When all the objects in a subregion 
become inaccessible, the subregion is flushed, i.e., all objects 
allocated inside it are deallocated. We do not flush a subre- 
gion if its counter is positive. Furthermore, we do not flush 
a subregion r if any of its portal fields is non-null (to allow 
some thread to enter it later and use those objects) or if 
any of r’s subregions has not been flushed yet (because the 
objects from those subregions might point to objects from 
r). Recall that subregions are a way of “packaging” some 
data and sending it to another thread; the receiver thread 
looks inside the subregion (starting from the portal fields) 
and uses the data. Therefore, as long as a subregion with 
non-null portal fields is reachable (i.e., a thread may ob- 
tain a handler of it), the objects allocated inside it can be 
reachable even if no thread is currently in the subregion. 


2.3 Regions for Real-Time Programs 


A real-time program consists of a set of real-time threads 
with hard real-time constraints, a set of non real-time 
threads, and a special garbage collection thread. (This is 
a conceptual model; actual implementations might differ.) 
A real-time thread has strict deadlines for completing its 
tasks. Such a thread cannot afford to be interrupted for 
an unbounded amount of time by the garbage collector. 
However, the garbage collector cannot execute in parallel 
with a thread that creates/destroys heap roots, i.e., point- 
ers to heap objects, because this might cause it to collect 
reachable objects. Therefore, special care should be taken 
to ensure that the real-time threads do not hold and do not 


meth := t mn(formal*)((t p)*) effects where constr* {e} 
effects ::= accesses owner* 
srkind := ... as in Figure 7 ... | NHPRegion 
subsreg := srkind:rpol rsub 
rpol ::= LT(size) | VT 
k u=... as in Figure 3... | rkind:LT 


e 


.. as in Figure 7 ... | 
(RHandle(rkind:rpol r) h) { e } | 
NoGC_fork v.mn(owner*)(v*) 


Figure 9: Extensions for Real-Time Programs 


overwrite any heap reference. (The last restriction is needed 
to support copying collectors.) The language extensions for 
real-time programs are in Figure 9. 


Effects The expression “NoGC_fork v.mn(owner*)(vu*)” 
starts a real-time thread that is guaranteed not to require 
any interaction with the garbage collector. To statically 
check this, we introduce method effects. The effect clause 
of a method lists the owners (some of them regions) that 
the method accesses. Accessing a region means allocat- 
ing an object in that region. Accessing an object means 
reading/overwriting a reference to that object or allocating 
another object owned by it; notice that in our system read- 
ing/writing a field of an object is not considered an access to 
that object. If a method’s effects clause consists of the own- 
ers 01..n then that method and the methods it invokes and 
the threads that it starts (transitively) are guaranteed to 
access only objects and regions owned by 0}..n (transitively 
and reflexively). The typing rule for a NoGC_fork expression 
checks all the constraints for a normal fork expression: lo- 
cal regions or objects allocated in local regions cannot be 
passed to the started thread as owner/normal parameters. 
It also checks that no parameter is a heap object. Finally, 
it checks that none of the owners mentioned in the effects 
of the started thread method is heap or an object allocated 
in heap. If a NoGC_fork expression typechecks, the started 
thread does not receive any heap reference; also, it cannot 
obtain one by creating an object in the heap or by reading a 
heap reference from an object field: the type system makes 
sure that in both cases heap or an object allocated in heap 
appears in the method effects. 


Region Allocation Policies Our system supports two al- 
location policies for regions. One policy is to allocate mem- 
ory on demand, as new objects are created in a region. Our 
runtime system allocates memory at the granularity of mem- 
ory pages. For efficiency, we can have our own trivial alloca- 
tor run inside these pages. Pages allocated for a region can 
be chained into a linked list. We can maintain a pointer to 
the first free address inside the last page. When we need to 
allocate a new object, we can simply slide that pointer. If 
this makes the pointer go outside its page, we can allocate 
a new page, and allocate the new object at its beginning. 
Allocating a new object can take unbounded time (or might 
not even succeed), because of the possible memory page al- 
location. Flushing the region frees all the memory pages 
allocated for that region. Following the RTSJ terminology, 
we call such regions VT’ (Variable Time) regions. 

The other policy is to allocate all the memory for a region 
at its creation. The programmer must provide an upper 
bound for the total size of the objects that will be allocated 
in the region. Allocating an object requires sliding a pointer, 
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Figure 10: Some Typechecking Rules. The Complete Set of Rules is in the Appendix. 


but if we try to overflow the region, we do not allocate any 
new memory page. Instead, we throw an exception to signal 
that the region size was too small. Allocating a new object is 
linear in its size: sliding the pointer takes constant time, but 
we also have to set to zero each allocated byte. Flushing the 
region simply resets a pointer, and, importantly, does not 
free the memory allocated for the region. We call regions 
that use this allocation policy LT (Linear Time) regions. 
Once we have an LT subregion, we can repeatedly enter it, 
allocate objects in it, exit it (thus flushing it), and re-enter 
it without having to allocate a new chunk of memory. This 
is possible because flushing an LT region does not free its 
memory. LT regions are ideal for real-time threads: once 
such a region is created (with a large enough upper bound), 
all memory allocation will succeed, in linear time; moreover, 
the region can be flushed and reused without memory allo- 
cation. 

We allow the user to specify the region allocation pol- 
icy (LT or VT) when a new region is created. The pol- 
icy for the subregions is declared in the shared region kind 
declarations. When we specify an LT policy, we also have 
to specify the size of the region (in bytes). An expression 
“(RHandle(rkind:rpol r) h) {e}” creates a region with al- 
location policy rpol and allocates memory for all its (tran- 
sitive) (sub)regions (including itself) that are LT regions. 
Our type system checks that a region has a finite number of 
transitive LT subregions. Each time we enter a VT region, 
or an LT top level region (i.e., a region that is not a sub- 
region), the typechecker requires that heap is in the effects. 
This is not required when entering an existing LT subregion 
because no memory is allocated in that case. 


No Heap Pointers Regions The garbage collector needs 
to know all locations that point to heap objects, including 
those locations that are inside regions. Moreover, a moving 
collector might have to write to these locations. Suppose we 
have a real-time thread that uses an LT region that contains 
several such locations (these heap pointers might have been 
created by a non real-time thread). The real-time thread 
can flush the region (by exiting it), re-enter it and allocate 
objects inside it, thus possibly writing at any location in- 
side the LT region, including those that may be written by 
the garbage collector! There are several ways of solving this 
data race: 1) synchronize with the garbage collector, which 
might introduce unbounded delays, 2) use a conservative 
non-moving collector, and 3) require that a real-time thread 
uses only regions that do not contain any heap reference 
(regardless of whether the thread actually reads those ref- 
erences or not). Our system uses the third solution, which 
allows it to work with any garbage collector. 


We introduce a new shared region kind, NHPRegion (No 
Heap Pointers Region). A shared region of this kind does 
not contain any object with a field pointing to a heap object. 
Programmers can define shared region kinds that (transi- 
tively) extend NHPRegion. The extended owner kind hier- 
archy now includes all three areas from Figure 4. A real-time 
thread is allowed to enter only regions of kind NHPRegion 
(or a subkind of it). We enforce this by requiring that each 
time the program enters a region whose kind is not a sub- 
kind of NHPRegion, heap is among the effects. (Recall that 
the typing rule for NoGC_fork does not allow the body of a 
child thread to have heap in its effects.) To enforce that a 
NHPRegion region does not contain any heap reference, each 
time we enter such a region we check that the code cannot 
manipulate any heap reference, similar to the way we check 
a NoGC_fork expression. 


2.4 Rules for Typechecking 


The previous sections presented the grammar for our core 
language in Figures 3, 7, and 9. This section presents some 
of the important type rules. The full set of rules and the 
complete grammar can be found in the appendix. Figure 10 
presents several (simplified) typechecking rules from our sys- 
tem. At the core of our type system lies a set of rules of 
the form P;E;X;rer - e : t. Such a rule means that in 
program P, environment F and current region re,, expres- 
sion e has type t, and accesses only objects/regions that 
are owned by the owners from the effect list X. The en- 
vironment E stores information about the identifiers from 
the current scope: the type of each variable, the owner kind 
of each formal owner parameter or region, and the own- 
ership/outlives relation between these owners. Formally, 
E:=@|E,tv|&, ko| ££, 0 =.01 | E, 02201. 

A useful auxiliary rule is E+ X1 >>, Xo, i-e., the effects 
X 1 subsume the effects X2: Vo € Xe, dg € Xi, s.t. g =o 0. 
To prove constraints of the form g >. 0, g = o etc. in a spe- 
cific environment FE, the checker uses the constraints from 
E, and the properties of > and ~.: transitivity, reflexivity, 
>. implies >, and the first owner from the type of an object 
owns the object. 

The expression “(RHandle(r) h) {e}” creates a local re- 
gion and evaluates e in an environment where r and h are 
bound to the new region, respectively to its handle. The 
associated rule constructs an environment F»2 that extends 
the original environment E by recording that r has kind 
LocalRegion and h has type RHandle(r). As r is deleted at 
the end of e, all existing regions outlive it; E2 records this 
too. e should typecheck according to the environment E2 
and the permitted effects X,r (the local region r is a per- 
mitted effect inside e). Because creating a region requires 


memory allocation, X must subsume heap. The expression is 
evaluated only for its side-effects; this way, we avoid prob- 
lems with the case when e evaluates to an object from r. 
Hence, the type of the entire expression is int. 

The rule for a field read expression “e.fd” first checks e 
and finds its type cn(o1..). Next, it verifies that fd is a field 
of class cn; let t be its declared type. We obtain the type 
of the entire expression by replacing in t each formal owner 
parameter fn, of cn with the corresponding owner o;. If the 
expression reads an object, the rule checks that X subsumes 
the owner of that object. 

In the case of “new cn(o1..n)”, we first check that the 
class cn is defined in P. Next, we check that each formal 
owner parameter jn, of cn is instantiated with an owner 0; 
of appropriate kind, i.e., the kind k/ of 0; (provided by F) 
is a subkind of the declared kind of fn;. We also check that 
in E, each owner o; outlives the first owner 01, and each 
constraint of cn is satisfied. Allocating a (sub)object means 
accessing its owner; therefore, we require that X subsumes 
01. The new object is allocated in the region 0; stands for 
(if it is a region) or 01 is allocated in (if it is an object). 
The rule £ Fay RH(01) checks that a handle for this region 
is available. If 0; € {heap, immortal} this is trivially true; 
otherwise, we use the bottom four rules from Figure 10. 
If 01 is a region, the first rule looks for its handle into the 
environment. The next two rules use the fact that all objects 
are allocated in the same region as their owner. Therefore, 
if 01 =o o2 and we have the region handle for one of them, 
we have the region handle for the other one. Finally, our 
runtime is able to find the handle of a region where an object 
(this in particular) is allocated. Notice that these rules do 
significant reasoning, thus reducing annotation burden. 

The case of fork is similar to that of a method call. In ad- 
dition, the rule checks that the started thread receives only 
regions that are not local (i.e., GCRegion and SharedRegion 
regions) or objects allocated in such regions. For this, it re- 
trieves the kinds of the regions that the owners stand for or 
are allocated in and checks that none of these is LocalRegion; 
similarly for the kinds of the regions where the parameters 
are allocated. The rules for retrieving these region kinds (not 
shown here) are similar to those for checking that a region 
handle is available, rules that we explained in the previous 
paragraph. The key idea they exploit is that a subobject is 
allocated in the same region as its owner. 


2.5 Type Inference 

Although our type system is explicitly typed in principle, 
it would be onerous to fully annotate every method with the 
extra type information that our system requires. Instead, 
we use a combination of inference and well-chosen defaults 
to significantly reduce the number of annotations needed in 
practice. We emphasize that our approach to inference is 
purely intra-procedural and we do not infer method signa- 
tures or types of instance variables. Rather, we use a default 
completion of partial type specifications in those cases. This 
approach permits separate compilation. 

If owners of method local variables are not specified, we 
use a simple unification-based approach to infer the owners. 
The approach is similar to the ones in [9, 7]. For parameters 
unconstrained after unification, we use initialRegion. For un- 
specified owners in method signatures, we use initialRegion as 
the default. For unspecified owners in instance variables, we 
use the owner of this as the default. For static fields, we use 
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Figure 11: Translation of a region with three fields 
and two subregions. 


immortal as the default. Our default accesses clauses contain 
all class and method owner parameters and initialRegion. 


2.6 Translation to Real-Time Java 


Although our system provides significant improvements 
over RTSJ (static guarantees, subregions etc.), our language 
can be translated to RTSJ in a reasonably easy way, by local 
translation rules. This is mainly due to the fact that being 
able to do type erasure was a key design goal; e.g., region 
handles exist specifically for this purpose. Also, RTSJ has 
mechanisms that are powerful enough to support our fea- 
tures. RTSJ offers LTMemory and VIMemory regions where 
it takes linear time, respectively variable time to allocate 
objects. RTSJ regions are Java objects that point to some 
memory space. In addition, RTSJ has two special regions: 
heap and immortal. A thread can allocate in the current 
region using new. A thread can also allocate in any re- 
gion that it entered using newInstance, which requires a 
region object. RTSJ regions are maintained similarly to our 
shared regions, by counting the number of threads executing 
in them. RTSJ regions have one portal, which is similar to 
a region field except that its declared type is Object. Most 
of the translation effort is focused on providing the missing 
features: subregions and multiple, typed region fields. We 
discuss the translation of several important features from 
our type system; the full translation is discussed in [35]. 

We represent a region r from our system as an RTSJ re- 
gion m plus two auxiliary objects wi and w2 (Figure 11). m 
points to a memory area that is pre-allocated for an LT re- 
gion, or grown on-demand for a VT region. m also points 
to an object w1 whose fields point to the representation of 
r’s subregions. (We subclass LT/VTMemory to add an extra 
field.) In addition, m’s portal points to an object w2 that 
serves as a wrapper for r’s fields. w2 is allocated in the 
memory space attached to m, while m and wi are allocated 
in the current region at the moment m was created. 

The translation of “new cn(o1..,)” requires a reference 
to (i.e., a handle of) the region we allocate in. If this is 
the same as the current region, we use the more efficient 
new. The type rules already proved that we can obtain 
the necessary handle, i.e., E Fay RH(01), using the four bot- 
tom rules from Figure 10. Those rules “pushed” the state- 
ment F Fay RH(o) up and down the ownership relation until 
we obtained an owner for which we can obtain the handle: 
immortal, heap, this, or a region for which we have a vari- 
able that holds the region handle. RTSJ provides mech- 
anisms for retrieving the handle in the first three cases: 
ImmortalArea.instance(), HeapArea.instance(), respec- 
tively MethodArea. getMethodArea(Object). In the last case, 
we simply use the handle variable. 


Program | Lines of Code | Lines Changed 
Array 56 4 
Tree 83 8 
Water 1850 31 
Barnes 1850 16 
ImageRec 567 8 
http 603 20 
game 97 10 
phone 244 24 


Figure 12: Programming Overhead 


Execution Time (sec) 
Program Static Dymanic Overhead 
Checks Checks 
Array 2.24 16.2 7.23 
Tree 4.78 23.1 4.83 
Water 2.06 2.55 1.24 
Barnes 19.1 21.6 1.13 
ImageRec 6.70 8.10 T21 
load 0.667 0.831 1.25 
cross 0.014 0.014 1.0 
threshold 0.001 0.001 1 
hysteresis 0.005 0.006 1 
thinning 0.023 0.026 1.1 
save 0.617 0.731 1.18 


Figure 13: Dynamic Checking Overhead 


3. RESULTS 


To gain preliminary experience, we implemented several 
programs in our system. These include two synthetic pro- 
grams (Array and Tree), two scientific computations (Water 
and Barnes), several components of an image recognition 
pipeline (load, cross, threshold, hysteresis, and thinning), and 
several simple servers (http, game, and phone, a database- 
backed information sever). In each case, once we understood 
how the program worked, adding the extra type annotations 
was fairly straight forward. Figure 12 presents a measure of 
the programming overhead involved. The figure shows the 
lines of code that needed type annotations. In most cases, 
we only had to change code where regions were created. 

We also used our RTSJ implementation to measure the 
execution times of these programs both with and without 
the dynamic referencing and assignment checks as speci- 
fied in the Real-Time Specification for Java. Figure 13 
presents the running times of the benchmarks both with 
and without dynamic checks in the absence of garbage col- 
lection. Our synthetic programs (Array and Tree) were writ- 
ten specifically to maximize the check overhead—our de- 
velopment goal was to maximize the ratio of assignments 
to other computation. The synthetic programs exhibit the 
largest performance increases—they run approximately 7.2 
and 4.8 times faster, respectively, without checks. The per- 
formance improvements for the scientific programs and im- 
age processing components provides a more realistic picture 
of the check overhead. These programs have more modest 
performance improvements, running up to 1.25 times faster 
without checks. For the servers, the running time is domi- 
nated by the network processing overhead and check removal 
has virtually no effect. We present the overhead of dynamic 
referencing and assignment checks in this paper. For a de- 
tailed analysis of the performance of a full range of RTSJ 
features, see [15, 16]. 


4. RELATED WORK 


The seminal work in [37, 36] introduces a static type sys- 
tem for region-based memory management for ML. Our sys- 
tem extends this to object-oriented programs by combining 
the benefits of region types and ownership types in a unified 
type system framework. Our system extends region types 
to multithreaded programs by allowing long-lived threads 
to share objects without using the heap and without having 
memory leaks. Our system extends region types to real-time 
programs by ensuring that real-time threads do not interfere 
with the garbage collector. 

[2] provides a static analysis to free some regions early 
to avoid the constraints of LIFO region lifetimes in [37, 
36]. Capability Calculus [17] proposes a general type sys- 
tem for freeing regions based on linear types. Vault’s type 
system [19] allows a region to be freed before it leaves scope. 
These systems are more expressive than our framework. How- 
ever, these systems do not handle object-oriented programs 
and the consequent subtyping, multithreaded programs with 
shared regions, or real-time programs with real-time threads. 
Moreover, we can augment our system with linear types and 
other techniques used in the above systems. In fact, other 
systems have already combined ownership-based type sys- 
tems and unique pointers [11, 9, 3]. 

RegJava [30] describes a region type system for object- 
oriented programs that handles subtyping and method over- 
riding. We improve on this by combining the benefits of 
ownership types and region types in a unified framework. 
Cyclone [26] is a dialect of C with a region type system. An 
extension to Cyclone handles multithreaded programs and 
provides shared regions [25]. Our work improves on this 
by providing subregions in shared regions and portal fields 
in subregions, so that long-lived threads can share objects 
without using the heap and without having memory leaks. 
Other systems for regions [23, 24] use runtime checks to en- 
sure memory safety. These systems are more flexible, but 
they do not statically ensure safety. 

To our knowledge, ours is the first static type system that 
handles memory management in real-time programs. [31, 
20] automatically translate Java code into RTSJ code us- 
ing off-line dynamic analysis to determine the lifetime of 
an object. Unlike our system, this system does not require 
type annotations. It does, however, impose a runtime over- 
head and it is not safe because the dynamic analysis might 
miss some execution paths. Programmers can use this dy- 
namic analysis to obtain suggestions for region type anno- 
tations. If a program typechecks, the suggested annotations 
were sound. We expect such tools to be of great value in 
helping programmers write precise type annotations. We 
previously used escape analysis [34] to remove RTSJ run- 
time checks [33]. However, the analysis works only for some 
programs. Our type system is more flexible. 


5. CONCLUSIONS 


The Real-Time Specification for Java (RTSJ) allows a pro- 
gram to create real-time threads with hard real-time con- 
straints. The RTSJ uses runtime checks to ensure mem- 
ory safety. This paper presents a static type system that 
guarantees that these runtime checks will never fail for well- 
typed programs. Our type system therefore 1) provides an 
important safety guarantee for real-time programs and 2) 
makes it possible to eliminate the runtime checks and their 


associated overhead. Our system also makes several con- 
tributions over previous work on region types. For object- 
oriented programs, it combines region types and ownership 
types in a unified type system framework. For multithreaded 
programs, it allows long-lived threads to share objects with- 
out using the heap and without having memory leaks. For 
real-time programs, it ensures that real-time threads do not 
interfere with the garbage collector. We have implemented 
several programs in our system. Our experience indicates 
that our type system is sufficiently expressive and requires 
little programming overhead. We also ran these programs 
on our RTSJ platform. Our experiments show that elimi- 
nating the RTSJ runtime checks using a static type system 
can significantly speed-up a real-time program. 
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APPENDIX 
A. COMPLETE GRAMMAR 


P ::= def* srkdef* e 
def := class cn(formal+) extends c where constr* {field* meth*} 
formal := k fn 
c = cn(owner+) | Object(owner) 
owner ::= fn |r| this | initialRegion 
field = tb fd 
meth ::= t mn(formal*)((t p)*) effects where constr* {e} 
effects ::= accesses owner™ 
constr ::= owner owns owner | owner outlives owner 
t := c| int | RHandle(r) 
srkdef ::= regionKind srkn(formal*) extends srkind where constr* {field* subsreg*} 
subsreg ::= srkind:rpol rsub 
srkind ::=  srkn(owner*) | SharedRegion | NHPRegion 
rkind ::=  srkind | Region | NoGCRegion | GCRegion | LocalRegion 
rpol ::= LT(size) | VT 
k ::= Owner | ObjOwner | rkind | rkind:LT 
e := vu|h-heap | himmortal | let v = e in { e }| 
v.fd | v.fd =v | v.mn(owner*) (v*) | new c | 
fork v.mn(owner*)(v*) | NoGC_fork v.mn(owner*) (v*) | 
(RHandle(r) h) { e }| 
(RHandle(rkind:rpol r) h) { e 
(RHandle(r) h = [newlopt h.rsub) { e } | 
h.fd|h.fd = v 
Ls 1g 
cn © class names 
fd €_ field names 
mn € method names 
fn € formal identifiers 
v,p © variable names 
r €- region identifiers (including heap and immortal) 
srkn © shared region kind names 
rsub © shared subregion names 
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B. TYPE RULES 


In this section, we formally describe our type system. To simplify the presentation of key ideas, we 
describe our type system in the context of the previously introduced small language. However, our approach 
extends to the whole of Java and other similar languages. Throughout this section, we try to use the same 
notations as in the grammar. To save space, we use o instead of owner and f instead of formal. We also 
use g and a as alternate variables ranging over the set of owners. We also suppose the program source has 
been preprocessed by replacing each constraint “o; owns 02” with non-ASCII, but shorter form “o, =» 02” 
and each constraint “o, outlives 02” with “o, > 09.” 

The core of our type system is a set of typing judgments of the form P; E; X;r., e: t. The meaning of 
such a rule is that in the context of the program P, environment EF, e yields type t and accesses only objects 
(transitively) owned by the owners from X (X is simply a list of owners: X ::= 0*). P, the program being 
checked, is included to provide information about class definitions. The typing environment E provides 
information about the type of the free variables of e (t v, i-e., variable v has type t), the kind of the owners 
currently in scope (k o. i.e., owner o has kind k), and the two relations between owners: the “ownership” 
relation (02 =p 01, i.€., 02 Owns 01) and the “outlives” relation (02 = 0}, i.e., 02 outlives 0,). More formally, 
E::=@|E,tv|E, ko| FE, 02 >01 | E, 02 = 04. 

The table below presents the format and the meaning of all our typing rules: 


Typing rule Meaning 

Pst Program P has type t. 

PF ae def def is a well formed class definition from program P. 

PFgkaer srkdef : srkdef jisa well formed shared region kind definition from program P. 


PLE;X3Te Fe:t | In program P, environment /£, and current region r,,, expression e has 
type t. Its evaluation accesses only objects (transitively) outlived by 


owners listed in the effects X. 
Bene wh FE is a well formed environment with respect to program P. 


P 
PEF imeth meth Method definition meth is well defined with respect to program P and 
environment E. 


Pi mbréc Class c defines or inherits “member” definition mbr. “Member” refers 
to a field or a method: mbr = field | meth. 
PE rmbr € rkind | Shared region kind rkind defines or inherits “region member” defini- 


tion rmbr. “Region member” refers to a field or a subregion: rmbr = 
field | subsreg. 


P, E Feype t t is a well formed type with respect to program P and environment EL. 

PEt, <te ty is a subtype of tg, with respect to program P. 

P, EF oxina k k is a well formed owner kind, with respect to program P and environ- 
ment FE. 

PE ky <, ko ky is a subkind of ko, with respect to program P and environment EF. 

BE Xo > X41 Effect X1 is subsumed by effect X2, with respect to environment E. 

EF constr In environment EF, constr is well formed (i.e., the owners involved in it 
are well formed) and satisfied. 

Eryo:k In environment EF, o is a well formed owner with kind k. 

EF. RKind(o) = k | Owner o is allocated in a region of kind k. 

E+, RKind(v) =k | v points to an object allocated in a region of kind k. 

E Fay RH(o) The handle of the region o is allocated in (if o is an object) or o stands 
for (if it is a region) is available in the environment EF. 

EF 02 > 01 In environment £, owner 02 (an object or a region) owns owner 0; (which 
must be an object). 

EF 02 = 04 In environment E, owner 02 outlives owner 0}. 


We use several auxiliary predicates, almost all of them very straightforward. The only exception is 
InheritanceOK (P) which will be defined formally later. The table below presents a description of these 
auxiliary predicates: 
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Predicate Meaning 

WFClasses(P) No class is defined twice and there is no cycle in the class hierarchy. 

WF RegionKinds(P) | No region kind is defined twice and there is no cycle in the region kind 
hierarchy. 

FieldsOnce(P) No class or region kind contains two fields with the same name, either 
feelin Se 

MethodsOnce(P) No class declares two methods with the same name. 


InheritanceOK(P) | The requirements (i.e., constraints) of a sub-class/kind are included in 
the super-class/kind requirements. For overriding methods, in addition 
to the usual subtyping relations between the return/parameter types, 
the requirements of the overrider are included in the overridden method 
requirements; similarly for the effects. This predicate will be formally 


defined later. 


B.1 Well Typed Programs: | P: ¢ 


[PROG] 


WF Classes(P) WFRegionKinds(P) FieldsOnce(P) MethodsOnce(P) InheritanceOK (P) 
P= def,., srkdef,, ¢ VWie{l.n}, Prager def, Vie {l.r}, Plerkder srkdef ; 
P;); world; heap + e : t 
F P: t 


B.2 Well Formed Environments: P',.,, £ 


[ENV 0) [ENV v] [ENV OWNER] [ENV a [ENV x] 
PFeny E PFeny E PFleny E PFeny E 
v € Dom(E) o € Dom(E) E Fy 01 : ObjOwner EPs @isike 
PLE Ktype t P; EF oxina & Eb, oa:k EF, 02: ko 
TF ane 0 Pireay Eye PFeny E, ko PVleny EB, 01 =o 02 PFeny &, 01 = 02 


where ene =D 
Dom(E, tv) = {v}U Dom(E) 
Dom(E, ko) = {o}U Dom(E) 
Dom(E, -) = Dom(E£), otherwise 


B.3 Well Formed Class Definitions: P| g.¢ def 


[CLASS DEF] 


def = class cn((kj fn;)ieqi.m}) extends c where constr. {field,_,,, methi.p} P=... def .. 
E= 0, (kj friietin}s constr y..c, en(fny. n) this, (fn; = ny )ief2..n} Prey EO PE hae c 
Vj € {1..m}, (field, =tj fd; P,EMtype t;) Vk e {lp}, P; EF meth meth, 
Pie dep 


B.4 Well Formed Shared Region Kind Definitions: P| .:.ae¢ srkdef 


[REGION KIND DEF] 


srkdef = regionKind srkn((kj fn;)icefi.n}) extends r where constry.. { field, subsreg,, } 
P=... srkdef ... 
b= 0, (kj frietrn}s constr .c, srkn (fry. n) this, (fn; la this) sef1..n} Prep E P;E Voting © 
Vj € {1..m}, (field; =t; fd; P; E Mtype t; 
Vk € {1..s}, (subsreg, = srkind, rsub, P; EF srkina srkind,) 


P Ferkdef srkdef 
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B.5 Well Formed Types: P; E Ftype t 


[TYPE INT] [TYPE OBJECT] [TYPE REGION HANDLE] 
Er, o:k Etyr:k PEk<, Region 
P, EF Ftype int P; E Ftype Object(o) P, E Ftype RHandle(r) 
[TYPE C] 
PS ate UES ate def = class cn((ki fni)ieti.n}) -- Where constri.c ... 


Voe inthe Pe ork A: PRR Sok Wd Fone 67) 
Vi € {1..c}, EF constr;[o1/fn4]..[on/fn»| 
PEE Vigne, C0101.) 


B.6 Subtyping Rules: Pt t, < te 


[SUBTYPE REFL] [SUBTYPE TRANS] [SUBTYPE CLASS) 
PEt, < te PFaep class cn((ki fn;)ie{i.n}) 
Prigsts extends cno(fn, o*) ... 
PFt<t PFE <t3 PF en(or.n) < eng(fnry 0*)[o1/fry]..[on/ fry] 


B.7 Well Formed Owner Kinds: P; Eb oking & 


[STANDARD OWNERS] [LT REGIONS] 
k € {Owner, ObjOwner, Region, GCRegion, 
NoGCRegion, NHPRegion, LocalRegion, SharedRegion } P. FE Foxina rkind 
P, E Fokina & PEF oxina rkind :LT 


[USER DECLARED SHARED REGION] 


Pt skaet regionKind srkn((k; Iri)ie(r.n}) .. where constry.¢ «.. 
VWi€ {1..n}, (E Fy O;: k; Pre kj <k kj) 
Vi € {l..c}, EF constr;{o1/fn4]..[on/fny| 
P; E' Fokina srkn(01..n) 


B.8 Owner Subkinding Rules: P+ k, <, ko 


[SUBKIND OWNER] [SUBKIND REGION] [SUBKIND NOGCREGION] 
k € {ObjOwner, Region} k € {GCRegion, NoGCRegion} k € {LocalRegion, SharedRegion} 
PEk<, Owner PEk<, Region PE k<, NoGCRegion 
[SUBKIND NHPREGION] [SUBKIND SHARED REGION KIND] 
Pl srkdet regionKind srkn((ki fni)ieginy) extends r ... 
Pt NHPRegion <; SharedRegion PF srkn(01..0n) <«¢ [01 /fn4]--[on/ fra] 
[DELETE LT] [ADD LT] 


PE rkind, <, rkinds 


PFE rkind: LT <, rkind PFE rkindy:LT <, rkindg:LT 

[SUBKIND REFL] [SUBKIND TRANS] [SUBKIND VALUE] 
PEK <x ko PE ko <x kg 

PFESF PEky <, kg PF Value <<, k 
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B.9 Well Formed Methods: P; EF + yt meth 


[METHOD] 


E'=E, fin, constri.ic, (tj Pi)je(. p}> Region initialRegion, RHandle(initialRegion) hfresn 
eae Ee PR ay. qi initialRegion F e: t 
POE Peet. bmn fin) (Cy Dee accesses a, where constr). {e} 


B.10 Methods/Fields Defined in a Class: Pt field € c and Pt meth € c 


In the next two rules, let mbr = field | meth be a class member (i.e., a field / method definition). 


[DECLARED CLASS MEMBER] 


Plaet class en((ki fni)ietin}) {mor ... } 
PE mbr € cn(fn4_») 


(INHERITED CLASS MEMBER] 


Pt mbr € cn(fny_») 
Ptaep class cno((k; ini ieft.m}) extends cn(01_n)..- 


PP mbr |o1/fr4]..[on/fny| € eng (fn). m) 


B.11 Subregions/Fields Defined in a Region Kind: Pt field € rkind and 
PF subsreg € rkind 


In the next two rules, let rmbr = field | subsreg be a region member (i.e., a field / subregion definition). 


[DECLARED REGION MEMBER] 


Pl srkaep regionKind srkn((kj fn; )ietin}) -- { -- rmbr ... t 
PE rmbr € srkn(fny.n) 


(INHERITED REGION MEMBER] 


Pt rmbr € srkn(fny, ») 
Pt skaet regionKind srkn((k; niieta.m}) extends srkn(01..) ... 
PF rmbr[o,/fny]..[on/fnn] € srkna(fn’), ») 


B.12 Effect subsumption: E+ X, =, X2 


[X1 =o Xo] 
Xy=%.n X2= Jim 
Vi € {ln}, Aj e {lm}, Bk 0; ~o % 
EF X= Xo 


We frequently use a special case of this rule, E+ X >, 0, where the second effect, i.e., list of owners, 
consists of a single owner. 


B.13. Provable Constraints: E+ constr 


[ENV CONSTR] 
E= E},, constr, Ee 
EF constr 


15 


[=o world] [=. OWNER] (=. REFL] (=. TRANS] 


E =F, cn(01..n) this, Eo Et 01 Xo 02 Elk 02 &¢ 03 
EF world = 0 EF 0, &o this EFo},o EF 01 Xo 03 
eee | [> heap/immortal] [> REFL] [> TRANS] 
EF 01 &o 02 01 € {heap, immortal} Eto>og Eb o.> 03 
EF o1 = 02 EF o1 = 02 EFro=o EF oj = 03 


B.14 Well Formed Owners: Et, 0:k 


[OWNER THIS] [OWNER FORMAL] 

B= Fi, cn...) this, E B= Fi, k 0, E» 
EF, this : Owner BE, o:k 

[OWNER HEAP] [OWNER IMMORTAL] 


EF, heap : GCRegion EF, immortal : SharedRegion 


B.15 Region Kind: £ +, RKind(o) =k and E+, RKind(v) =k 


[RKIND THIS} [RKIND FN1| [RKIND FNQ| 
Er, o:k 
Ekyo:k k © {Owner, ObjOwner} 
E+, RKind(this) = k k € {Owner, ObjOwner} EF o2>o0 EF > RKind(o2) = ko 
EF, RKind(this) = & EF. RKind(o) = k EF. RKind(fn) = ke 
[RKIND INT] [RKIND CLASS] 
E= Ej, cn{01.n) v, Eo 

E= EF, int v, Eo Eko RKind(0}) =k 

EF, RKind(v) = Value EF, RKind(v) = k 


B.16 Available Region Handlers: FE +,,, RH(o) 


[AV HEAP] [AV IMMORTAL] [AV HANDLE] 


E = E\, RHandle(r) h, EF 
E Fay RH(heap) FE Fay RH(immortal) E Fay RH(r) 


[AV THIS] [AV TRANS]] [AV TRANSQ] 
B= Fy, cn(01,.n) this, E» EF 01 => 02 E Fay RH(02) EF 01 =o 02 E Fay RH(01) 


E Fa, RH(this) E Fay RH(01) E Fay RH(03) 


B.17_ Well Typed Expressions: P, E; X; 1. e:t 


[EXPR VAR] [EXPR LET] [EXPR NEW] 
Pode Xr Pee tf = Bhi wo PE ie “C= en 01) 
E=E£), t v, E> Psy BPE EX te Fes tp Ebay RH(o1) EE X &> 01 


PLES X3rep Fut PLE; X31Tep F let uv = e, in e€2: te PLE; X3Tep FH new c:¢ 
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[EXPR H_-HEAP] [EXPR H_IMMORTAL] 


P; E; X; rey F h_heap : RHandle(heap) P, EX; rey F h_immortal : RHandle (immortal) 


[EXPR REF READ] [EXPR REF WRITE] 
PTI EXS Fee Oh CAO ae) 
P. EEX: tee Fut C001, 9) Pi E; X3 ep & v9 3 te 
PF (¢ fd) € en(fny n) PF (¢ fd) € eni (fry n) 
U = t[o1/fny]:-[on/ fr t= to /fny|.-[on/fn,| Pte? 
t' = cn(o, m) 27 EEX Xo Oo} tU=cn'(gi.m) ~EFX=og 
POERX ta vga oe PLE: Xs Ter F up.fd = v2: 0 


[EXPR INVOKE] 


Pi ES X;rer Hu: en(oy.n) Vie {(n+1).m}, BF oj = oO 
Prt mn((ki fn; )ieg(ngt).my) (ty Pi)jefa.ny) accesses Xm where constri.< {e} € cn(fny_,) 
Rename(a) es aloi/fn4]..[Om/ frm] [Ter /initialRegion] 
Vie {1k}, (PRE; X3re but A PEt < Rename(t;)) 
Vi € {(n+1)..m}, (EF, a; kf A PE ki <, Rename(k;)) 
Et} X &> Rename(Xm) Wi € {1..c}, EF Rename(constr;) 
PES X35 rep F v.mn (On 41)..m) (U1..k) + Rename(t) 


[EXPR REGION] 


P; EF oxina rkind =rkind = srkn() Pt rkind <, Region 
— { rkind:LT if rpol = LT (size) 


rkind otherwise Bay ep ey Hand Lecr ht 


E; = { Eo, (Te = T)¥reeRegions(z) if PF rkind <, LocalRegion Phew Es 
{oe X | Et, RKind(o) =k A Pr ki <~ NoGCRegion} 
X2= if PF rkind <, NHPRegion 
X otherwise 
P, E3;Xo,r,rrhe:t EEX =, heap 
Pt rkind <, NHPRegion — Vu © FreeVars(e), (Ey RKind(v) =k A PE k <, NoGCRegion) 
P. E; X;1r-y F (RHandle(rkind:rpol r) h) {e}: int 


where Free Vars(e) is the set of free variables from e and Regions(E) is the set of all regions mentioned in 
E: 
Regions() 0 
Regions(E) U {r} 


Regions(E, rkind r) 
Regions(E, -) Regions(E), otherwise 


Ey otherwise 


[EXPR SUBREGION] 


P; EF; X3 rer F hg: RHandle(m) Eby rm: srkn2(01,.n) 
Pt rkind3:rpol rsub € srkno(fny_,) rkind = rkind3|o1/fn4]..[on/fn,»][r2/this] 
kp = { ies “ET De oe Eo = E, kp r, RHandle(r) h, rer Preny Eo 
{oe X | Et, RKind(o) =k A PE k; <~ NoGCRegion} 
Xo = if P+ rkind <, NHPRegion 
X otherwise 
P; Eo; Xo,r;rF-e:t 
new V -=(PE rkind <, NHPRegion) V (rpol =VT) — EF X =, heap 
Pt rkind <, NHPRegion — Vv € FreeVars(e), (E Fy RKind(v) =k A Pt k <x NoGCRegion) 
PE; X31 F (RHandle(r) hy = [newlopt ho.rsub) {e}: int 
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[EXPR LOCALREGION] 


P, E; X;1ep / (RHandle(LocalRegion: VT r) h) {e}: int 
P; E; X;1r- F (RHandle(r) h) {e}: int 


[EXPR FORK] 
Py EEX ten ug in On A Oia) et 


NonLocal(k) “! (P+ k <, SharedRegion) V (P+ k <, GCRegion) 
Vi € {0..k}, (EB Fy RKind(v;) = k; A NonLocal(k)) 
Vi € {l..n}, (BF, RKind(o;) = ki A NonLocal(k;)) 
E+, RKind(rer) = ker NonLocal(Ker) 
PE; X3 rep F fork v9.mn(0j1..n) CYy,.~) + int 


[EXPR NOGCFORK] 


Vi € {0..m}, (EF Fy, RKind(w) =k A Pt kj <, SharedRegion: LT) 
Vi € {l..n}, (EF, RKind(o;) = ki A Pt ki <, SharedRegion: LT) 
Et, RKind(re,) = ker P+ ker <_ SharedRegion: LT 
X'’={0€ X | E+, RKind(o) =k A Pt ki <, SharedRegion} 
PEE  Capt0g TR Oia ican) 2b 
P; EX; rer F NoGC_fork up.mn(o1..n) CU1..m) : int 


[EXPR GET REGION FIELD] 


PE; X3rep bh: RHandle(r) EF, r: srkn(0j..n) 
Pt t fd € srkn(fny_,) t =tloi/fny]..[on/fn,|[r/this] 
PER eet: Ue Sint) Vv te = cho) AOE Pe 0)) 
POE Xie fete t 


[EXPR SET REGION FIELD] 


P; EX; rer Hh: RHandle(r) Et, r: srkn(o1.n) 
Pet fd € srkn(fny,) ti =tloi/fnq]..[on/fn,][r/this] 
Poh xine eat PP ay BPX eer 
PLE; X3te HA. fd = v: ty 


B.18 Correct Method Overriding: [nheritanceOK (P) 


[INHERITANCEOK PROG] 


P= def, ,, srkdef, , e Vie {1..n}, Pk InheritanceOK (def ;) 
Vi € {l..r}, PE InheritanceOK (srkdef ;) 
InheritanceOK (P) 


[INHERITANCEOK CLASS} 


def =class cn((kj fn;)ieti.n}) extends cn(o1,.m) where constr1.q «.. 


def' = class cn'((ki fni)icgim}) extends c where constr{,, ... 
PFaet def’ constr1..u{o1/fn}.-[om/fnin] G constr’, 4 
Ymn, ( Pk methedef A meth=t, mn(...)C..) .. A 
Pt meth’ € def’ A meth =t, mni(...)C..) .. ) 
— Pt OverridesOK (meth, meth’) 


PF Inheritance OK (def ) 
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[OVERRIDESOK METHOD] 


meth =t, mn(fi.n)Cti Pi)ie{1.m}) accesses i,q where constri., ... 
meth’ =t!. mn(fi.n) C(t Pi )ie{1..my) accesses a‘, , where constr, ,, ... 
PEt <t Wie (ium), PRE <t 
ag FU.s constr, S constri. 


P+ OverridesOK (meth, meth’) 


(INHERITANCEOK REGION KIND] 


srkdef = regionKind srkn(fi.») extends srkn’(o1,m) where constri.¢ .. 


srkdef' = regionKind srkn’((ki fni)iet1.m}) extends srkind where constr’, ... 


Pt ekaet srkdef’ constry,,,[01/fn].-[Om/fnin] C constr) 4 


PF InheritanceOK (srkdef ) 
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C. TRANSLATION TO RTSJ 


In this section, we present details on how we translate programs written in our system to RTSJ programs 
using local translation rules. The following subsections show the translation for expressions that create or 
enter regions, access region fields, allocate objects, or start threads. The translation for the other language 
constructs is trivial—we do a simple type-erasure based translation. In this section, we use bold font for 
the generated code and italic font (default font for mathematical notation in AT@X) for the expressions 
that are evaluated at translation time. 


C.1 Region Representation 


Similar to our system, RTSJ allows the programmers to create memory regions (“memory areas” in 
RTSJ terminology). It also has two special memory areas: a garbage-collected heap and an immortal 
memory area. A memory area is a normal Java objects that also point to a piece of memory for the 
objects allocated in that memory area. Figure 14 presents the RTSJ hierarchy of classes for memory 
management. The root of this hierarchy, MemoryArea, is subclassed by HeapMemory, ImmortalMemory and 
ScopedMemory. HeapMemory and ImmortalMemory represent the heap, respectively the immortal memory 
area; there exists only one instance of each of them. ScopedMemory is the class for normal regions; it 
has two subclasses: LTMemory (for LT regions) and VIMemory (for VT regions). The RTSJ regions are 
maintained similarly to our shared regions: each thread has a stack of regions it can currently access, and 
each region has counter of how many threads can access it. 


RTSJ 
MemoryArea 


HeapMemory ImmortalMemory ScopedMemory IRegion 


Irkind, _~ Irkind, 


LTMemory VTMemory 


LTrkind, VIrkind, 


Figure 14: RTSJ hierarchy of memory management related classes and our extensions to it. 


We translate each region from our system into a memory area and some additional objects. Figure 15 
presents the translation into RTSJ of a region r with three fields and two subregions. We represent r as 
an RTSJ memory area m plus two auxiliary objects w1 and w2. m points to a piece of memory that is 
pre-allocated for an LT region, or grown on-demand for a VT region. m also points to an object w1 whose 
fields point to the representation of r’s subregions (we subclass LT/VTMemory to add an extra field); these 
subregions are represented in the same way as r. (Note that we only allow a region to have a bounded 
number of subregions.) In addition, m’s portal points to an object w2 that serves as a wrapper for r’s 
fields. w2 is allocated in the memory space attached to m, while m, wi, and all the similar objects for the 


Portal 


aes O for region m 


Region | J 
fields ud. 
El allocated 


inm 


Subregions 


Figure 15: Translation of a region with three fields and two subregions 
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public interface Irkind extends IRegion { 
rkindSubs getSubs() ; 
rkindFields getFields() ; 


i 


public class rkindFields { 
V field (t fd) € rkind 
public ¢ fd; 


‘i 


public class rkindSubs { 
V subregion (srkinds:rpol, rsub) € rkind 
public Isrkinds, rsub; 


Figure 16: Declaration of Irkind for representing regions of kind rkind 


public interface IRegion { 
boolean isFlushed() ; 


void setIsFlushed(boolean value); 
void tryToFlush() ; 


boolean isASubregion() ; 


void setIsASubregion(boolean value) ; 


AtomicInteger getNInside() ; 
AtomicInteger getNExiting() ; 


Figure 17: Declaration of [Region, the common super type of Irkinds 


representation of r’s transitive subregions are allocated in the current region at the time m was created. 


There are several differences between RT'SJ memory areas and our regions. The following list presents 
them, together with our translation for each case; Figure 16 presents the classes and interfaces we introduce 
along the way. 


1. To ensure proper nesting of memory area enter/exit operations, RTSJ uses the following mechanism 
for executing code inside a memory area: the program calls the enter method of the memory area 
object and passes it a Runnable object; the run() method of this object is executed inside the memory 
area. To translate an expression of the form “(RHandle(rkind:rpol r) h) {e}” into this pattern, we 
have to create Runnable objects. 


2. RTSJ does not have thread-local memory areas. Therefore, we have to translate the local regions into 
memory areas that are maintained through thread counting; even if we know that only one thread 
uses them. This is less efficient than a genuine implementation of local regions but is still correct. 


3. An RTSJ memory area has one portal field, similar to our region fields, except that it is untyped 
(ie., has type Object). To allow multiple and typed region fields, for each region kind rkind from 
our system, we introduce a field wrapper class rkindFields (Figure 16) that contains a field for each 
original field. For each region of kind rkind, the portal of the corresponding memory area points to 
an object of class rkindFields allocated in that memory area. 


4. RTSJ does not have anything equivalent to our subregions. To simulate them, for each region kind 
rkind, we introduce a subregion wrapper class rkindSubs (Figure 16) that has one field for each 
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import javax.realtime.*; 


import java.util.concurrent.atomic.*; 


public class LTrkind extends LTMemory implements Irkind { 
private boolean isFlushed; 
public boolean isFlushed() { return isFlushed; } 
public boolean setIsFlushed(boolean value) { isFlushed = value; } 
private boolean isASubregion; 
public boolean isASubregion() { return isASubregion; } 
private rkindSubs subs; 
public rkindSubs  getSubs() { return subs; } 
public rkindFields getFields() { return (rkindFields) getPortal(); } 
private AtomicInteger n_inside = new AtomicInteger(0); // number of threads inside 
public AtomicInteger getNInside() return n_inside; 
public AtomicInteger n_exiting = new AtomicInteger(0); // number of threads exiting 


public AtomicInteger getNExiting() return n_exiting; // See JSR 166 


public LTrkind (boolean isASubregion, int size) { 
super (size) ; 
this.flushed = true; this.isASubregion = isASubregion; 
this.subs = new rkindSubs(); 
Vv subregion (srkinds:rpol, rsub) € rkind, generate 
subs.rsub = 
if rpol, = LT(size) new LTsrkinds(true, size) ; 
else new VTsrkind, (true) ; 


public void tryToFlush() { 
if(canFlush()) { 

setIsFlushed(true); setPortal(null1) ; 

rkindSubs subs = getSubs(); 

if(!isASubregion()) { 

V subregion (rkinds:rpol, rsub) € rkind, generate 

IRegion sr = subs.rsub; 
if(!sr.isFlushed()) sr.tryToFlush() ; 


I} 


private boolean canFlush() { 
if (getReferenceCount() != 1) return false; 
if(!isASubregion()) return true; 
rkindFields fields = this.getFields() ; 
if(fields != null) { 
V field (t fd) € rkind, generate 
if(fields.fd != null) return false; 
} 
rkindSubs subs = this.getSubs() ; 
V subregion (srkinds:rpol, rsub) © rkind, generate 
if (!subs.rsub.isFlushed()) return false; 


return true; 


} 


Figure 18: Declaration of class LTrkind. LTrkind represents regions of kind rkind, with allocation policy LT. 
The declaration of VT rkind, the VT version, is almost identical, except that it subclasses VTMemory and its 
constructor does not take any size parameter. 
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subregion. Subregions are represented similar to their parent region. When we create a region, we 
automatically create all its transitive subregions. All the memory area objects and the field wrappers 
are allocated in the current region at the creation time. Each memory area that represents a region of 
kind rkind implements the interface Irkind (Figure 16); this interface has special methods for retrieving 
the field wrapper object and the subregion wrapper. In addition Irkind extends the interface IRegion 
(Figure 17) that has some region maintenance methods. 


5. Our RTSJ platform flushes a memory area when its counter changes from one to zero and its portal 
is null. While designing our language, our goal was as follows. We wanted to provide semantics where 
flushing or deleting of regions is transparent to programs (so one cannot detect under program control 
if a region has been flushed or deleted). However, we also wanted to reclaim memory space as soon as 
possible. We therefore came up with the following rules for flushing a region: we flush a subregion if 
the counter is zero, all fields are null and all subregions have been flushed; we flush a region as soon 
as its counter is zero (because the region won’t be used afterward). To enforce our rules, at each place 
where we might exit a region we call its method tryToFlush(). This method acts as follows: if the 
counter is about to become zero and our other conditions are satisfied, we set the portal field to null 
such that RTSJ flushes that region; otherwise, we let it be non-null to prevent the region from being 
flushed. 


In RTSJ, the programmer chooses the desired allocation policy by allocating a LTMemory or a VIMemory 
object. Hence, for each region kind rkind, we define two implementations of Irkind: a class LTrkind 
that extends LTMemory, and a class VIrkind that extends VIMemory. This creates the class hierarchy 
from Figure 14. Figure 18 presents the declaration of LTrkind. VIrkind is almost identical, except that 
it inherits from VTMemory, and its constructor does not take any size argument. As Java does not have 
multiple class inheritance, there is significant code duplication between LTrkind and VTrkind. This can be 
improved by factoring out most of the code as static methods in one of the two classes. 

In our system, we have both region names and region handles. The region names are for typechecking 
purposes only that are removed by the type erasure. The region handles are runtime values; a region 
handle that had the type RHandle(r) in our system is translated into a reference to an object Irkind, 
where rkind is the kind of the region r. 


C.2 Creating a Default Local Region 


Instead of presenting directly the translation for general region creation expression of the form 
“(RHandle(rkind:rpol r) h) {e}”, we first look at a simplified case. An expression of the form 
“(RHandle(r) h) {e}” creates a local region (i.e., a region of kind LocalRegion) using the default alloca- 
tion policy VT. Figure 19 presents the translation for “(RHandle(r) h) {e}”. The code from Figure 19 
works as follows: 


1. Create region h = new VTLocalRegion (false) 


2. Declare a class RE that implements the Runnable interface. Its run() method serve as a wrapper for 
the expression e. We introduce several fields in RE for dealing with the free variables of e. For each 
such variable v # this, RE has a field v of appropriate type. If this appears in e, we create a field 
with a fresh name _this (this refers to another object in the methods of RE). The body of the run() 
method consists of e, with each free occurrence of this substituted by _this. 


3. We create an instance re of RE in the current region and initialize its fields with the free variables of 
€. 


4. Execute e: h.enter(re) ; 


5. Retrieve the (possibly changed) values of the free variables of e from re’s fields. 


C.3 Creating a Shared Region 


The translation for “(RHandle(rkind:rpol r) h) {e}” is very similar to that for a local region, with 
the following differences: 


1. We replace line 1 with the following code: 
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// create a new RTSJ region 


1: ILocalRegion h = new VTLocalRegion(false) ; 


// create a Runnable object to wrap the code of e 
class RE implements Runnable { 
// one field for h and for each free variable of e 
2:  ILocalRegion h; 
Vu € FreeVars(e) \ {this}; let t be its type in the environment 
public ft v; 
if this € FreeVars(e); let t be its type in the environment 
public ¢ _this; 


public void run() { 
3: translation of e[_this/this] 
} 


; 
RE re = new RE(); 


// store h and all free variables of e in re’s fields 
re.h =h; 
Vu € FreeVars(e) \ {h, this} 
Te.U = U3 
if this € Free Vars(e) 
re._this = this; 


// evaluate e 
((MemoryArea) h).enter(re) ; 


// restore the values of e’s free variables 
Vu € FreeVars(e) \ {h, this} 
v = re.v; 


i 


where RE, re, and -_this are fresh identifiers. 


Figure 19: Translation for “(RHandle(r) h) {e}” 
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1’: Irkind h = 
if (rpol = LT(size)) new LTrkind (true, size); 
else new VTrkind (true) ; 


Accordingly, field h of the class RE (line 2) has now type Irkind. 
2. The body of the run() method of class RE (line 3) is replaced with 


public void run() { 


int x = h.getNInside().add(1); 
while (h.getNExiting().get() > 0) sleep(0,1000); // Wait until exiting threads finish exiting 
if (x == 1) { 
h.setIsFlushed (false) ; 
if (h.getPortal() == null) h.setPortal(new rkindFields()); 
} else { 
while (h.getPortal() == null) sleep(0,1000) ; 


} 
try { 
translation of e[id/this] 
} finally { 
h.getNExiting().add(1); // Begin exiting the region 
int x = h.getNInside() .add(-1); 
if (x == 0) A.tryToFlush() ; 
h.getNExiting() .add(-1); // Finish exiting the region 
} 
} 


At the beginning of the run() method, if this is the first thread entering the region, we mark the 
region A as unflushed and make sure it has a non-null portal. By using the try-finally block, we 
ensure that no matter how e terminates, we execute some code right before run() is exited and the 
counter of memory area h is decremented. The method h.tryToFlush() enforces our region flushing 
policy. 


In the above code, both the beginning and the end of run() access the isFlushed field from the region 
object (indirectly via tryToFlush) and its portal. We avoid race conditions with a tricky synchro- 
nization mechanism that uses atomic operations defined in JSR 166 [27]. Our synchronization ensures 
safety: when a thread is using a region, no other thread can flush the same region; and when a thread 
is using a region, the region has a non-null portal. Our synchronization also ensures that the last 
thread exiting a region flushes the region if the conditions for flushing are met. 


Note that the above code has a priority inversion problem. In the above code, a thread entering a 
region waits if there are threads exiting (and perhaps flushing) the region. The process of exiting the 
region only takes a bounded amount of time, so normally, the wait should be for a bounded amount of 
time. However, when a regular thread is exiting the region, it might be suspended for an unbounded 
amount of time by the garbage collector. If a real-time thread then wants to enter the region, it might 
have to wait for an unbounded amount of time for the regular thread to finish exiting the region. 


The above priority inversion problem occurs even in the Real-Time Specification for Java, so we do no 
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worse than the RTSJ. However, it is possible to modify our type system slightly to avoid the priority 
inversion problem. We describe the modifications in Section C.9. 


C.4_ Entering a Subregion 

The translation for “(RHandle(r) h = hg.rsub) {e}” is very similar to the one from Section C.3. The 
only difference is that now, instead of creating a region, we simply read one and use it. The beginning of 
the translation (line 1’) becomes: 


1°’: Isrkind h = hz.getSubs() .h; 


where rkind is the kind of the subregion rsub. 


C.5 Creating a Subregion 


The translation for “(RHandle(r) h = new hg.rsub) {e}” is very similar to the one from Section C.3. 
Only the beginning of the translation changes as follows: 


1’??: class RE implements Runnable { 
VTIMemory h; 
VTMemory ho; 
public void run() { 
h= 
if rpol, = LT(size) new LTrkind,(true, size) ; 
else new VTrkind, (true) ; 
hg.subs.rsub = h; 
} 
} 


MemoryArea ma = MemoryArea.getMemoryArea(hz) ; 
h2.subs.rsub.setIsASubregion (false) ; 

RE re = new RE(); 

re.h = h; re.ho = ho; 

ma.enter (re) ; 


h = re.h; ho = re.ha; 


where rkind, is the kind of the subregion rsub, rpol, is its allocation policy, and RE, re, and ma are fresh 
identifiers. The above code works as follows: 


1. To be consistent with our representation of regions (see Section C.1), we allocate the memory area 
objects for the new subregion (and its subregions) in the same memory area where the previous 
subregion was allocated. Most of the above code deals with technical details related to this operation. 


2. The previous subregion is “detached” from its parent: “hg.subs.rsub.setIsASubregion(false)” to 
record the fact that it cannot be entered from its parent. The first time its counter becomes zero, it 
will be flushed (and subsequently deleted along with its subregions). 


C.6 Manipulating Region Fields 
We translate “h.fd” as follows: 


((rkindFields) h.getPortal()).fd 


where rkind is the kind of the region r that h is a handle of, i.e., in the type environment, h has type 
RHandle(r). The translation for “h.fd = v” is similar: 


((rkindFields) h.getPortal()).fd = v 
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C.7 Allocating an Object 


There are no constructors in the language we presented so far. However, they are trivial to add: an 
expression of the form “new cn(01,.n)(€1..m)” desugars into a “new cn(01,.,)” followed by a call to the 
appropriate constructor. We translate “new cn(01,.n) (€1..m)” as follows: 


1. First, we generate Java code to retrieve the memory area where the new object is allocated. The type 
rule for new already checked that FF, RH(0}1), ie., a handle for this region is available at runtime, 
even after type-erasure (see the rules from Section B.16). We use the typechecker judgments to retrieve 
that region. Notice that each of the rules that prove a statement of the form EF, RH(o) has at most 
one such statement among its preconditions. Therefore, if we consider the part of the proof tree for 
EF ay RH(01) that corresponds only to this kind of rules, we obtain a chain. We can retrieve the 
relevant memory area in all cases: 

AV HANDLE] The typing environment contains a handle h of type RHandle(r) for 

the relevant region r. In the translated code h is a local variable that 

points to the region we allocate in; we directly use (MemoryArea) h. 


AV HEAP] Allocation in heap; call HeapMemory.instance(). 
AV IMMORTAL] | Allocation in immortal; call ImmortalMemory.instance(). 
AV THIS] Allocation in the region this is allocated in; call 


MemoryArea. getMemoryArea(this) 


2. Next, we generate a call to newInstance, to allocate a new object in the memory area that the 
code generated at 1 evaluates to. We also recursively translate e1, ..., €m (the arguments of the 
constructor). 


Optimization: newInstance allows us to allocate an object in any region. However, it currently uses 
reflection, e.g., for passing the class of the allocated object. Hence, it is less efficient than new, that 
allocates only in the current region. The typechecker knows the current region r,, for the new expression 
that we translate. For [AV HEAP], [AV IMMORTAL] and [AV HANDLE}, if r¢, is identical to the region 
we allocate in, we use new. We can apply this optimization even in the case of [AV THIS], if the typechecker 
can prove that re, =, this. 


C.8 Forking a Thread 


Figure 20 presents the translation for an expression of the form “fork ug.mn(01,.n) (W1.m)”. The re- 
sulting code works as follows: 


1. In Java, threads are objects whose class is a subclass of java.lang.Thread. Programmers create 
thread objects using new and start them by invoking their start() method. start() starts a thread 
whose body is the run() method of the thread object. In RTSJ, threads that want to use regions 
have to subclass javax.realtime.RealtimeThread, which itself subclasses java.lang.Thread. Ac- 
cordingly, we define a class T for our thread. T has one field vi to store the value of each variable 
Uj. 

2. The run() method of T invokes mn with the right receiver and parameters. When the thread ter- 
minates, each region that is still on its stack of regions is exited. Therefore, for each such region, if 
our conditions for flushing it are fulfilled, we need to make sure that it meets the conditions for being 
flushed by RTSJ. Fortunately, RTSJ offers methods that allow us to examine the stack of memory 
areas associated with a thread. 

3. We create a instance of class T’, generate code to store the result of each variable v; in the appropriate 
field and next start the thread. 

The only difference in the translation for “NoGC_fork v9.mn(0q,.n)(V1,.m)” is that we subclass T from 
NoHeapRealtimeThread, instead of RealtimeThread. In RTSJ, a NoHeapRealtimeThread is not inter- 
rupted by the garbage collector because it cannot manipulate heap references. RTSJ ensures this using 
dynamic checks. Our system ensures this statically, so we can remove these dynamic checks if an RTSJ 
platform allows us to do so. 


C.9_ Avoiding Priority Inversion Using Static Type Checking 


Recall the priority inversion problem from Section C.3. A real-time thread entering a region waits for 
threads exiting (and perhaps flushing) the region. If a regular thread exiting the region is suspended (for 
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{ 


class T extends javax.realtime.RealtimeThread { 
Vi € {0,...,m}, one field to store the value of ui (of type ti): 
ty vt; 
public void run() { 
try { 
vO.mn(vi,..., vm); 
} finally { 
for(int i = 0; i < getMemoryAreaStackDepth(); i++) { 
IRegion isr = (IRegion) getQuterMemoryArea(i) ; 
synchronized(isr) { isr.tryToFlush(); } 
} 
} 
} // end of run() 
} 
T t = new T(); 
Vi € {0,...,m} generate one line of the form: 
t.vi = U3 
t.start(); 


i 


where T and ¢ are fresh identifiers. 


Figure 20: Translation for “fork vp.mn(o1..n)(U1..m)” 


an unbounded amount of time) by the garbage collector, the real-time thread might have to wait for an 


unbounded amount of time before being able to enter the region. 


We can avoid this problem by modifying our type system slightly. Note that the problem occurs only 
when a regular thread and a real-time thread share a region. Note also that the problem occurs only when 
a real-time thread is trying to enter a region. But since a real-time thread cannot create new regions, 
it can only enter sub-regions of shared regions. Therefore, if we prevent regular threads and real-time 


threads from sharing the same sub-regions, we can avoid the priority inversion problem. 
Here are the necessary extensions to the type system to achieve this: 


1. For space reasons, we use the names GC, NoGC threads for normal, respectively real-time threads. 
For each subregion declaration, we ask the programmer to specify whether that subregion is 1) a 
GC subregion (i.e., only GC threads can access it) or 2) a NoGC region (i.e., only NoGC threads can 
access it). We introduce a grammar rule for the thread types tt and we update the grammar rule for 


subregion declarations: 


tt GC | NoGC 


subsreg ::= srkind:rpol tt rsub 


2. When we enter a subregion, we can find out from its declaration whether it is a GC or a NoGC 
subregion. We need to check that the current thread has the appropriate thread type (GC or NoGC). 
For this, we modify the type judgments for expressions P; E; _X; re, / e : t to keep track of the possible 
types of threads that can execute e. The new type judgments have the form P; E; X;r.-;T'F e : t, 
where T C {GC, NoGC} is the set of types of the threads that may execute e. Most of the rules just 


propagate T without using it. The rule for entering a subregion is one of the exceptions: 


[EXPR SUBREGION] 
E; X3 rep; ho; Pb RHandle(r2): EF, m: srkn2(01..n) 
Pt rkind3:rpol tt rsub € srkno((ki fni)iegi.ny) T= {tt} 


... the other antecedents are unchanged ... 
PLE; X; rep; TF (RHandle(r) hy = [new]opt ho.rsub) {e}: int 
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This way, only a normal (ie., GC) thread can execute an expression that enters a GC subregion. 
Similarly, only a real-time (i.e., NoGC) thread can execute an expression that enters a NoGC subregion. 
Expressions that do not enter any subregion can be executed by any thread. 


. Each method declaration should specify the types of the threads that may execute it: 
meth := t mn(formal*)((t p)*) effects where constr* callableFrom it* {e} 


By default, if a method declaration does not have any callableFrom clause, we assume the method is 
declared as callable from any thread, i.e. “callableFrom GC,NoGC”. The list of thread types from 
the method declaration is used while typechecking the expression e, the body of the method: 


[METHOD] 


ESE, fies Constriey Cy Pidje(. vy, Region initialRegion, RHandle(initialRegion) hfresh 
Pin dh - Pele a4. qi initialRegion; TF e :t 
Pee Pek tm fine OG D5) je {1..p}> accesses @j,q where constr;,. callableFrom T {e} 


Therefore, if a method declares that a normal (i.e., GC) thread may call it, then that method cannot 
be called from a NoGC thread. 


. The rule for a fork expression checks that the initial method invoked in the child thread may be called 
from a GC thread. Analogously, the rule for a NoGC_fork expression checks that the corresponding 
method may be called from a NoGC thread. 


. We update the rule for method invocation to check that the set of types of the threads that may 
execute the call expression is included in the set of types of the threads that may execute the invoked 
method: 


[EXPR INVOKE] 


Pe tal DO Cen Oty) 
Pet mn fn+1).m) C(t; Dj) jef1..K}? ... callableFrom Tip, {e} € cn(fi.n) 


... the other antecedents are unchanged .. 
PLEX ites Tl FO O41) ga) Oe * Renaniels) 
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